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REMARKS 

Claims 1, 3, 4, 6-9, 11-15, 17-19, 21, 22, and 24-30 are currently pending in this present 
application. Claims 1, 3, 4, 6, 7, 11, 13, 17, 19, and 24 have been changed, claims 5, 10, 16, and 
23 have been cancelled, and claims 25-29 have been added by this amendment. No new matter 
has been added. Reconsideration of this patent application is respectfully requested. 

A telephone interview was held with the Examiner on February 12, 2009, in which 
several issues discussed and arguments presented included in the remarks below, and in which 
no agreement was reached. 

103 Rejections 

The Examiner rejected claims 1, 7, 13, and 19 under 35 U.S.C. 103(a) as being 
unpatentable over "ORMCC: A Simple and Effective Single-Rate Multicast Congestion Control 
Scheme," ("Li") in view of U.S. Pub. No. 2002/0123309 ("Collier"), U.S. Patent No. 5,253,325 
("Clark"), and U.S. Patent No. 6,993,587 ("Basani"). Applicant respectfully traverses, and has 
amended the claim for clarification. 

Claim 1 includes receiving multicast packets at a master client in a multicast transfer, 
wherein at least one passive client listens in on the transferred multicast packets to receive the 
multicast packets. It is determined, by the passive clients during the multicast transfer, which is 
a slowest passive client based on which passive client drops a highest number of packets, and the 
slowest passive client is made a new master client and the master client is made one of the 
passive clients. A number of dropped packets during a multicast transfer are counted by a drop 
packet counter of each passive client. A drop ratio is computed when the count of the number of 
dropped packets reaches a predetermined count threshold. If the drop ratio reaches a 
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configurable threshold, a Force Master command is sent to the server requesting to become the 
new master client, and the drop packet counter is restarted in each passive client after the master 
client has been made into one of the passive clients. 

In contrast, Li discloses a system in which, at the arrival of a packet, a receiver detects 
that "some" packets have been lost, and the receiver sends out a congestion indication and a 
output rate of data to the server only if the average output rate is below the average minus the 
deviation. The output rate (measured when packet losses are detected) is averaged over a short 
period of time (such as 1 second) and the slowest receiver is located by the server using the 
results (Page 3, Section HI, A. (1), (2), (4)). 

Li does not disclose or suggest computing a drop ratio when a count of dropped packets 
reaches a predetermined count threshold. Li measures an output rate when any packet losses are 
detected, but only over a short period of time such as one second, and thus does not maintain a 
count of dropped packets during a multicast transfer and compute the drop ratio when the 
number of dropped packets reaches a predetermined threshold. 

Furthermore, Li does not disclose or suggest restarting the drop packet counter in every 
passive client after the master client has been made into one of the passive clients based on a 
slowest client's drop ratio. Li discloses using independent receivers that each continually track 
their own output rates in the same way regardless of the status of a congestion representative. In 
Li, there is no coordination in clients, such as the restarting of a drop packet counter in each 
passive client after a master client is made into a passive client as claimed. 

The Examiner cited Collier as counting at a receiver the rate at which packets are 
dropped. However, nowhere does Collier disclose or suggest restarting a drop packet counter in 
each passive client after a master client has become a passive client based on a slowest client' s 
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drop ratio, as recited in claim 1. Collier only broadly discloses monitoring signal quality by 
counting packet drop rate, and discloses or suggests nothing about coordinating the reset of drop 
counters in multiple clients based on a master status, as recited in claim 1. 

The Examiner cited Clark for teaching the calculation of a ratio when a count exceeds a 
threshold and performing a computer-related task if the ratio meets a threshold. However, 
nowhere does Clark disclose or suggest restarting a drop packet counter in each passive client 
after a master client has become a passive client based on a slowest client's drop ratio, as recited 
in claim 1. Furthermore, Clark only broadly discloses calculating a compression ratio and 
checking if a compression ratio is above a threshold, which is concerned with compression of 
data and is not related to dropped packets or network transfers, and therefore Clark is not a 
reference one of ordinary skill of the art would combine with references in a field of Applicant' s 
invention. 

The Examiner cited Basani as teaching a Force Master command. However, nowhere 
does Basani disclose or suggest restarting a drop packet counter in each passive client after a 
master client has become a passive client based on a slowest client's drop ratio, as recited in 
claim 1. In addition, Basani does not disclose Applicant's claimed Force Master command. 
Basani discloses a "group leader" in a network segment or cluster that is used to handle store- 
and-forward to other sites in the cluster, local distribution of content to other backend servers, 
and provide site reports back to a content control manager (col. 13, lines 60-67, col. 14 lines 1- 
3). Thus, the group leader receives data from the server and then distributes the data to other 
servers in that leader's group. This group leader is not a master client in a multicast transfer as 
recited in Applicant's claim 1. A master client in Applicant's claim 1 is in a multicast transfer, 
and the passive clients listen in on that multicast packet transfer to receive the packets. This is 
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not a store-and- forward scheme as used by Basani's group leader. Basani's "Leader claim" 
message is therefore not a Force Master command to cause a client to become a master client in 
the multicast transfer as recited in Applicant's cMm 1, but is a message to become a group 
leader in Basani's scheme. Thus the combination of Basani and the other references does not 
achieve Applicant's invention. 

With respect to former claims 5, 10, 16, and 23, the Examiner stated that Kidambi U.S. 
Patent No. 6,424,626, teaches resetting a dropped packet counter, e.g., at col. 7, lines 8-17. 
However, Kidambi discloses a system in which acknowledgements are intentionally suppressed 
to increase performance of the system (col. 2, lines 16-28, 47-50, col. 3, lines 41-48, col. 6, lines 
15-17). The drop counter of Kidambi is not used to observe how many packets are dropped due 
to a client processing too slowly, but is used to track how many acknowledgements are being 
intentionally dropped to improve performance. This drop counter value is inserted into the 
header and the drop counter is reset when an acknowledgement is needed and dequeued for 
transmission. At the receiving end, the receiver determines the number of acknowledgements to 
be regenerated at the receiving end by examining the drop counter value (col. 9, lines 50-58). 
Thus, ICidambi discloses that the number of acknowledgments being intentionally dropped is 
counted with a drop counter, and the drop counter is reset because an acknowledgement is 
needed to be sent from a queue. 

This is not like Applicant's claim 1, in which a drop packet counter counts a number of 
dropped packets that occur during a multicast transfer that are dropped due to passive clients 
having a processing speed sufficiently slow such that all received packets are not processed , and 
this drop packet counter is restarted after a master client has been made into a passive client . 
Kidambi' s drop counter is for a completely different use and purpose, and Kidambi does not 
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disclose or suggest a drop packet counter counting Applicant's dropped packets, nor restarting 
such a counter due to a master client being made into a passive client for a multicast transfer. 

In addition, claim 1 recites that the drop packet counter is restJirted in each passive client. 
Kidambi nowhere discloses restarting drop packet counters in all passive clients, and only 
discloses resetting a particular drop counter when an acknowledgement is sent from that 
counter's device 2. Thus, the combination of Kidambi' s drop counter with the other references 
does not achieve Applicant's invention. 

Therefore, none of the cited references discloses the use of a drop counter nor suggest 
coordinating the reset of drop counters in multiple clients based on a master status, as recited in 
claim 1. 

The Examiner cited Badovinatz as teaching multicasting a message informing group 
members of a new group leader (with respect to claims 3, 8, 14, and 21). However, Badovinatz 
does not disclose or suggest restarting drop packet counters in passive clients. 

Applicant therefore believe that claim 1 is patentable over these cited references. 

Claim 7 recites a method including counting a drop packet counter a number of packets 
dropping during a multicast transfer, computing a drop ratio, sending a Force Master command, 
and restarting the drop packet counter in each passive client, similar to claim 1, and is patentable 
over the references cited by the Examiner for at least similar reasons as explained above. Claims 
13 and 19 recite similar features and are patentable for at least similar reasons as explained 
above. 

Applicant therefore believes that claims 1,7, 13, and 19 are patentable over the 
combination of Li, Collier, Clark, and Basani, and further in view of Kidambi, and respectfully 
requests that the rejection under 35 U.S.C. 103 be withdrawn. 
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The Examiner rejected claims 3, 8, 14, and 21 under 35 U.S.C. 103(a) as being 
unpatentable over Li, Collier, Clark, and Basani, and further in view of U.S. Patent No. 
5,696,896 ("Badovinatz"). In addition to the differences explained above, Badovinatz simply 
discloses that a name server informs all other nodes in a group of a new group leader, and does 
not disclose or suggest sending a Drop Master command to a particular client that was once a 
master client b ut now is a passive client in a multicast transfer, and these cMms are therefore 
patentable over Badovinatz and the other references. 

The Examiner also rejected claims 4, 9, 15, and 22 under 35 U.S.C. 103(a) as being 
unpatentable over Li, Collier, Clark, Basani and Badovinatz, and further in view of what was 
well known. The Examiner also rejected claims 5, 6, 10-12, 16-18, 23 and 24 under 35 U.S.C. 
103(a) as being unpatentable over Li, Collier, Clark, Basani and Badovinatz, and further in view 
of BQdambi. The Examiner also rejected claims 6, 11, 17, and 24 under 35 U.S.C. 103(a) as 
being unpatentable over Li, Collier, Clark, Basani and Badovinatz. 

None of these cited references discloses or suggests the features of claim 1 similarly as 
explained above with reference to claim 1. Applicant therefore respectfully requests that the 
rejections be withdrawn. 

New Claims 

Claims 25-30 have been added and are dependent on the existing independent claims. 
These claims are believed patentable over the above references for at least the same reasons as 
their parent claims, and for additional reasons. 
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In view of the foregoing, Applicant submits that claims 1, 3, 4, 6-9, 11-15, 17-19, 21, 22, 
and 24-30 are in condition for allowance. Applicant respectfully requests reconsideration and 
allowance of the claims as now presented. Should £iny unresolved issues remain, Examiner is 
invited to call Applicant's attorney at the telephone number indicated below. 



Respectfully submitted, 
SAWYER LAW GROUP LLP 



February 16. 2009 /Joseph A. Sawyer. Jr./ 

Date Joseph A. Sawyer, Jr. 

Attorney for Applicants 
Reg. No. 30,801 
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(650) 493-4540 
(650) 493-4549 



17 



